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Abstract 

This  paper  reviews  two  relatively  new  tools  for  automated  formal  analyis  of  security  protocols. 
One  applies  the  formal  methods  technique  of  model  checking  to  the  task  of  protocol  analysis,  while 
the  other  utilizes  the  method  of  theory  generation,  which  borrows  from  both  model  checking  and 
automated  theorem  proving.  For  purposes  of  comparison,  the  tools  are  both  applied  to  a  suite  of 
sample  protocols  with  known  flaws,  including  the  protocol  used  in  an  earlier  study  to  provide  a 
baseline.  We  then  suggest  a  heuristic  for  combining  the  two  approaches  to  provide  a  more  complete 
analysis  than  either  approach  can  provide  alone. 
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1  Introduction 


Security  protocols  based  on  cryptographic  primitives  are  used  today  to  protect  computer  systems 
and  network  transactions  from  malicious  attacks.  These  protocols  have  been  known  to  be  notori¬ 
ously  hard  to  design  due  to  their  complexity.  Many  subtle  attacks  have  been  demonstrated  that 
are  difficult  to  catch  by  manual  analysis  alone.  There  is  therefore  a  need  for  formal  automated 
tools  to  assist  in  the  design  of  security  protocols. 

Many  researchers  have  recently  applied  automated  and  semi-automated  formal  techniques  to 
analyze  security  protocols.  These  tools  fall  into  roughly  two  classes  :  those  based  on  theorem 
proving  (e.g.,  [4,  10,  6])  and  those  based  on  model  checking  (e.g.,  [8,  9.  7]).  Tools  differ  in  the 
degree  of  automation  and  expressiveness;  often  more  automation  is  traded  off  against  reduced 
expressiveness.  Moreover,  the  assumptions  made  in  modelling  protocols  make  some  tools  better 
suited  than  others  in  catching  certain  classes  of  errors.  These  differences  indicate  that  we  might 
find  tools  that  complement  each  other. 

1.1  Model  Checking  and  Theory  Generation 

In  this  paper,  we  compare  two  recently  developed  automated  tools:  Brutus  [8],  which  is  a  model 
checker,  and  RVChecker,  which  is  based  on  Kindred’s  theory-generation  approach  [5]. 

Brutus  is  a  model  checker  specialized  to  analyze  security  protocols,  with  a  built-in  model 
of  the  adversary.  It  uses  standard  state  space  analysis  techniques  to  check  if  the  model  satisfies 
the  specification.  If  it  does  not,  then  Brutus  comes  up  with  a  counterexample  showing  where 
the  specification  breaks.  Although  model  checking  is  almost  entirely  ^‘push-button”  in  nature, 
Brutus  sometimes  comes  up  short  in  that  the  protocol  might  be  far  too  complex  to  handle  due 
to  state-space  explosion,  or  the  counter-example  might  be  too  complicated  to  understand  exactly 
what  assumption  breaks.  Even  if  these  do  not  happen,  it  is  possible  that  the  protocol  breaks  only 
when  a  certain  configuration  of  multiple  runs  occurs,  and  there  is  no  way  to  automatically  figure 
out  which  runs  are  important  for  analyzing  properties  of  interest. 

RVChecker  is  a  theory  generation  tool  based  on  Revere  [6]  which  is  based  on  belief  logics. 
The  core  idea  in  this  approach  is  to  produce  a  finite  representation  of  the  set  of  all  the  facts 
derivable  from  a  protocol  specification.  Verifying  a  particular  property  of  interest  then  simply 
becomes  testing  for  set  membership.  The  advantage  of  this  approach  lies  in  its  automation,  and 
in  the  high  level  handling  of  security  protocol  properties,  thereby  helping  the  designer  fix  incorrect 
assumptions  about  the  system  and  its  environment.  The  obvious  disadvantage  of  this  approach  lies 
in  the  difficulty  of  seeing  how  failure  of  certain  assumptions  can  translate  into  a  real  attack  on  the 
system.  For  a  fairly  complicated  interaction  between  assumptions,  it  might  be  very  difficult  for  a 
human  designer  to  figure  out  exactly  what  is  going  wrong. 

The  strengths  and  weaknesses  of  these  two  approaches  suggest  ways  of  combination.  In  the 
remainder  of  this  paper,  we  study  their  performance  on  a  suite  of  two  protocols  with  known  flaws. 
We  compare  the  performance  of  the  tools  on  these  two  protocols.  Based  on  this,  we  suggest  a  new 
method  of  analysis  based  on  a  complementary  combination  of  the  two  tools. 

1.2  The  Protocol  Suite 

We  ran  each  of  Brutus  and  RVChecker  on  a  suite  of  two  protocols,  both  of  which  are  known 
to  have  flaws.  This  suite  includes  the  Tatebayeshi-Matsuzaki-Newman  (TMN)  protocol  used  by 
Kemmerer,  Meadows  and  Millen  to  compare  three  analysis  tools  -  the  Interrogator,  InaJo  and 
the  NRL  Protocol  Analyzer  [4].  Using  this  protocol  thus  serves  to  provide  a  baseline  comparison 
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between  the  two  tools  investigated  here  and  the  three  systems  investigated  in  that  article.  Our 
suite  also  includes  the  buggy  namestamping  protocol  presented  by  Dolev  and  \ao  (D\)  in  their 
paper  on  algebra-based  analysis  of  security  protocols  [3].  The  chosen  protocols  help  to  illustrate 
the  relative  strengths  and  weaknesses  of  the  two  verification  approaches.  The  known  attack  on  the 
Dole\'-Yao  protocol  is  achieved  by  syntactic  manipulation  of  the  messages,  which  indicates  that  a 
model  checking  approach  that  explores  all  possible  operations  on  messages  might  catch  this  bug. 
On  the  other  hand,  in  the  TMN  protocol,  parties  perform  key  exchange  based  on  beliefs  about  the 
authenticity  of  the  other  party,  so  it  seems  that  a  belief  logic  based  tool  such  as  RVChecker  might 
catch  errors  in  this  protocol. 

1.2.1  Tatabayeshi-Matsuzaki-Newman  Key  Exchange  Protocol 

The  Tatabayeshi-Matsuzaki-Newman  (TMN)  protocol  for  key  exchange  [11],  features  a  server  5 
with  a  public  key  and  two  network  nodes  A  and  B  who  wish  to  exchange  a  session  key  through  the 
server.  The  protocol  consists  of  four  messages: 


1.  A- 

[S.A.B.{Ra}Ks] 

2.  S - 

B 

[B.S] 

S.  B- 

-^5 

[S.B.A.{Rb}Ks] 

4.  5- 

-4  A 

[A.S.B.Ra  ©  Rb] 

In  the  above  notation,  A  — >■  S  :  [S.A.B.{Ba}Ks]  means  that  the  composite  message  constructed 
by  concatenating  S,  A,  B  and  Ra  encrypted  under  As  is  sent  by  principal  A  to  principal  S.  Rx 
denotes  a  large  random  number  generated  b,y  principal  X ,  and  ©  denotes  bitwise  exclusive-or. 

After  a  run  of  this  protocol,  A  and  B  use  Rb  as  a  session  key.  The  protocol  falls  victim  to  several 
attacks.  One  attack  results  from  properties  of  the  public-key  and  symmetric  encryption  algorithms 
used  (RSA  and  XOR),  in  which  a  second  set  of  users  can  capture  some  of  the  messages  from  the 
first  protocol  instance  and  trick  the  server  into  revealing  the  key.  A  second  class  of  attacks  results 
from  the  fact  that  no  authentication  takes  place  in  the  protocol,  so  it  is  possible  for  an  intruder  to 
masquerade  as  an3'  of  the  other  principals  in  the  protocol  and  disrupt  the  network  by,  for  example 
learning  the  session  kej^s  of  principals  or  convincing  .4  that  he  is  securel,y  communicating  with  B 
when  in  fact  he  is  communicating  with  Z.  These  attacks  are  more  clearly  outlined  in  our  analj^ses 
in  Sections  2  and  3. 

1.2.2  Dolev- Yao  Namestamp  Protocol 

Dolev  and  Yao  [3]  introduce  several  simple  message  transfer  protocols  with  the  intent  of  proving 
them  secure  or  insecure.  All  of  the  protocols  involve  the  transmission  of  a  message  from  party  A 
to  party  B.  The  protocol  we  will  analyze  here,  which  has  a  multiple-run  attack,  has  two  messages 
(where  Kx  indicates  the  public  key  of  principal  X): 

A  — B  :  [A.{{M}Kb-A}Kh-B] 

B^A  :  [B.{{M}Ka.B}Ka.A] 

This  protocol  is  intended  to  securely  transfer  message  M  from  A  to  B,  but  the  double-encryption 
(added  to  another  protocol  which  Dolev  and  Yao  prove  secure  against  message  discovery)  allows  a 
three-run  attack  [3]: 

1.  Z  listens  to  the  first  run  of  the  protocol,  remembering  {{M}Ka-B}Ka  from  B‘’s  response. 
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2.  Z  initiates  the  protocol  with  A,  sending 

[Z.{{{M}K„.B]Ka.Z]Ka.A] 

3.  A  responds,  sending  Z: 

[A.{{{M}k„.B}k,.A}k,.Z] 

4.  Z  now  knows  {A/jA'a-  so  he  initiates  another  run  of  the  protocol  with  .4,  sending: 

[Z.{{M}Ka.Z]Ka.A] 

5.  A  responds  with: 

[  .4 .  {  {  A  /  }  A" ;  -4  }  A  : .  Z] 

6.  Z  now  has  the  message  M. 


Section  2  describes  Brutu.s  and  the  analysis  of  the  two  protocols  using  Brutus.  Section  3 
describes  RVChecker  and  the  analysis  performed  with  it.  In  Section  4  we  discuss  the  results  of 
our  analyses  and  in  Section  -5  we  propose  a  heuristic  to  combine  the  two  approaches.  Finally,  in 
Section  6  we  offer  concluding  remarks  and  suggest  avenues  for  further  research. 


2  Brutus 

Brutus  is  a  model  checker  specialized  for  analyzing  security  and  electronic  commerce  protocols  [8]. 
Like  most  model  checkers,  Bri'TUS  is  ba.sed  on  an  operational  description  of  the  behavior  of  par¬ 
ticipating  agents  (in  the  protocol),  based  on  which,  a  suitable  modal  logic  is  defined.  Properties 
expressed  in  this  logic  can  then  be  checked  against  the  model  using  state  space  analysis.  However, 
unlike  a  “general-purpose”  model  checker  in  which  the  u.ser  must  specify  a  finite  state  model  of  the 
intruder,  Brutus  has  a  built-in  model  of  the  intruder. 

In  this  section,  we  first  give  a  brief  overview  of  how  Brutus  models  a  protocol  and  how  it 
defines  and  checks  properties  of  interest.  Then,  we  use  Brutus  to  model  and  analyze  the  TMN 
and  Dolev-Yao  protocols. 

2.1  The  Model 

Brutus  specifies  that  the  protocol  must  follow  a  particular  model.  While  this  allows  us  to  formalize 
the  protocol  description  and  check  the  corresponding  logic  in  a  straightforward  way,  we  also  lose 
some  expressiveness  in  the  process. 

The  set  M  of  possible  messages  in  the  Brutus  model  of  protocols  can  be  defined  inductively 
as  follows  : 

1.  If  a  6  .4,  a  6  A4,  where  A  is  the  set  of  atomic  messages,  i.e.,  keys,  principal  names,  nonces 
or  data  messages. 

2.  If  ???i  €  M  and  m-i  €  M,  then  mi.m2  €  M  [pairing) 

3.  If  m  e  M  and  key  k  €  A,  then  {m}i,  €  M  (encryption) 
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In  Brutus,  the  principals  need  to  be  explicitly  modeled  in  the  protocol,  but  the  intruder  need  not. 
Brutus  instead  defines  a  derivability  relation^  “P’,  which  captures  how  the  intruder  can  derive  a 
message  from  some  initial  set  of  information  /. 

1.  If  777  G  1  then  /  h  m, 

2.  If  /  h  7?7i  and  /  h  m2  then  I  h  777i  •  7772.  (pairing) 

3.  If  /  h  7771  •  m2  then  I  h  7771  and  I  h  m2,  (projection) 

4.  If  /  h  777  and  I  h  k  for  key  k,  then  I  h  {m}k.  (encryption) 

5.  If  /  h  {777}^.  and  I  h  k~^  then  I  h  777.  (decryption) 

I  denotes  the  closure  of  I  under  application  of  the  above  rules. 

A  protocol  is  modeled  as  an  asynchronous  composition  of  communicating  processes  that  model 
the  honest  principals  as  well  as  the  intruder.  The  intruder  process  can  eavesdrop  on  all  commu¬ 
nication  and  can  interfere  by  dropping,  changing  or  adding  new  messages  in  any  way;  thus  the 
communication  channel  can  be  thought  of  as  passing  through  the  intruder.  The  model  is  made 
finite  by  imposing  a  bound  on  the  number  of  times  (^^sessions”)  a  principal  is  allowed  to  participate 
in  the  protocol. 

The  formal  model  of  an  individual  principal  in  a  single  session  is  called  an  instance.  Each 
instance  H  of  an  honest  principal  is  modeled  as  a  5-tuple  {N^  5,  /,  B,  P)  where: 

•  N  ^  names  is  the  name  of  the  principal. 

•  5  is  a  unique  instance  ID  for  this  instance. 

•  B:  vars{N)  — A4  is  a  set  of  bindings  for  vars{N),  the  set  of  variables  appearing  in  principal 
A^,  which  are  bound  for  a  particular  instance  as  it  receives  messages. 

•  /  C  A4  is  the  set  of  messages  known  to  the  principal  executing  the  instance  S. 

•  P  is  a  process  description  given  as  a  sequence  of  actions  to  be  performed.  These  actions 
include  the  pre-defined  actions  send  and  receive  ,  as  well  as  user  defined  internal  actions 
such  as  begin-response  and  end-response,  internal  actions  can  be  used  to  keep  track  of 
the  internal  state  of  an  instance. 

The  intruder,  Z,  is  not  bound  to  follow  the  protocol  and  the  intruder  process  neither  includes  a 
sequence  of  actions  Pz  nor  a  set  of  bindings  Bz.  Instead,  at  any  time,  the  intruder  can  receive  any 
message  or  it  can  send  any  message  it  can  generate  from  its  set  of  known  messages  Iz- 

The  states  of  all  processes  put  together  form  the  global  state  of  the  system.  Let  S  be  the 
set  of  global  states  of  the  system.  The  transition  relation  for  the  system  can  be  written  as  C 
Sx5xAxA4xS  where  S  is  the  set  of  global  states,  S  again  is  the  set  of  instance  IDs,  A  is  the 
set  of  action  names  (which  includes  send  and  receive  ),  and  M  is  the  set  of  all  possible  messages. 
A  transition  of  the  system  from  state  a  to  state  cr'  can  be  represented  as  a  cr'. 
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2.2  The  Logic 

The  property  of  interest  is  specified  in  a.  first  order  logic  with  finite  quantification  and  the  past-time 
temporal  operator. 

We  now  give  the  s\mtax  of  the  logic.  Atomic  propositions  in  the  logic  are  instance  IDs,  in¬ 
stance  variables,  message  constants  and  variables,  and  combinations  of  these  as  per  the  message 
construction  rules  defined  in  Section  2.1.  A  well  formed  formula  (wff)  in  the  logic  is  defined  as 
follows: 

•  if  /  is  an  atomic  proposition,  then  /  is  a  wff. 

•  if  /  is  a.  wff,  then  is  a  wff. 

•  if  /i  and  are  wffs,  then  /i  A  /2  is  a  wff. 

•  if  /  is  a  wff  and  -s  is  an  instance  variable,  then  3.5./  is  a  wff. 

•  if  /  is  a  wff,  then  Op/  is  a  wff.  ^ 

The  semantics  of  wffs  in  the  logic  are  defined  over  the  trace  of  states  and  actions  of  the  system 
TT  =  (Too  1(71  . .  .(7^,  and  can  be  given  bv  the  following  recursive  definition  of  the  satisfaction  relation 

N: 

•  (tt,  i)  1=  mi  =  1112  Iff  ==  the  interpretations  of  the  two  messages  in  the  ith 

state  must  be  the  same. 

•  The  formula  (tt,  i)  5  Knows  m  iff  cri{m)  e  Ij  for  some  instance  Hj  in  a{  such  that  Sj  =  5 

•  {[tt,  i)  [=  s  A  m  for  some  user  defined  action  A  iff  (7^_i 

The  usual  semantics  of  for  boolean  and  temporal  connectives  apply. 

Now,  if  we  need  to  model  check  a  given  property  p  defined  in  the  above  logic,  we  define  a  fixpoint 
operator  corresponding  to  the  temporal  operator  used.  The  state  space  can  also  be  encoded  as  a 
boolean  expression.  The  fixpoint  operator  is  then  applied  to  a  suitable  composition  of  the  state 
space  expression  and  the  property  formula.  When  the  computation  reaches  a  fixed  point,  we  can 
check  whether  the  property  holds  for  our  system.  If  the  property  does  not  hold,  the  resulting 
formula  will  encode  a  trace  which  shows  how  the  protocol  can  be  broken. 

A  detailed  treatment  of  model  checking  can  be  found  in  the  book  by  Clarke,  Grumberg  and 
Peled  [2]. 

2.3  Analysis 

We  now  describe  how  we  used  Brutus  to  model  and  analyze  the  TMN  and  Dolev-Yao  protocols. 
Each  analysis  of  a  property  described  in  this  section  ran  in  under  a  minute  on  an  Intel  Pentium 
II  300  MHz  machine  running  Linux.  Brutus  identified  some  of  the  flaws  in  both  the  protocols 
under  consideration,  however,  it  did  not  identify  all  of  the  known  flaws  due  to  limitations  in  its 
expressiveness. 

In  the  analysis  that  follows,  /  stands  for  the  intruder  and  all  other  letters  stand  for  honest 
principals  or  trusted  servers. 

^As  in  propositional  temporal  logic,  Op/  is  true  at  state  7,,  if  3  some  prior  state  (7j,j  <  i  where  /  holds. 
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2.3.1  Dolev-Yao  analysis 

The  initiating  and  responding  instances  of  each  honest  principal  are  modelled  as  shown  below  (each 
corresponds  to  one  session): 

INITIATOR  =  internal  ( ^egin  -  initiate",  b) 
send  (a,  b,  «}A'b) 

receive  {b,  a, 

internal  ( ^‘‘end  —  initiate",  b) 

RESPONDER  =  receive(a.  6.  -flA-fT/w.  a-Trc.) 

internal!  —  respond" ,  a) 

send(b,  a,  6}a-„) 

internal!  -  respond" ,  a) 

In  the  above  descriptions,  a  and  b  represent  the  names  of  the  two  communicating  parties. 

We  checked  the  following  classes  of  properties: 

•  Secrecy:  The  following  property  was  checked: 

-i(/  Knows  M) 

This  property  comes  out  to  be  true  when  we  model  less  than  three  sessions  of  the  initiator 
(.4)  and  less  than  two  sessions  of  the  responder  {B).  But  in  a  case  when  this  does  not  hold, 
where  there  are  three  sessions  of  A  and  one  of  B,  Brutus  finds  the  exact  same  attack  as  is 
described  in  [3].  Moreover,  we  find  alternative  ways  of  attacking  the  protocol  if  the  relative 
number  of  sessions  of  A  and  B  are  changed.  One  such  variation  occurs  when  B  listens  for 
two  sessions  and  A  initiates  using  one  session;  the  intruder  is  able  to  obtain  the  message  as 
shown  in  Figure  1. 

•  Authentication:  To  check  authentication,  we  checked  the  following  two  properties  : 

(1)  Va.{a  internal  {“’end  —  initiate" ,  B)  ^ 

{^Sb-iSb-P  =  B)A  Op  {Sb-P  internal  (“end  -  respond",  c)))} 

(2)  V6.{b  internal  {“end  —  respond".  A)  => 

{3Sa.{Sa-P  —  A) A  Op  (Sa-P  internal  {‘■‘’begin  -  initiate",  6)))} 

We  claim  these  properties  are  “authentication”  properties  —  the  first  claims  that  if  A  finishes 
initiating  a  message  to  a  honest  principal  B,  then  there  is  a  session  in  which  B  responded  to 
this  message  at  some  earlier  point  of  time.  The  second  claims  that  if  B  finished  responding 
to  a  message  apparently  from  A,  then  it  was  indeed  A  who  initiated  the  send  of  that  message 
in  some  session  at  some  time  in  the  past.  Note  that  these  are  rather  weak  conditions  of 
authenticity  which  rely  on  nametags  attached  to  messages  rather  than  something  more  secure. 
This  arises  from  the  fact  that  there  are  no  signatures  or  shared  secrets  involved  in  the  protocol. 
Properties  of  this  kind  have  also  been  referred  to  as  correspondence  properties  by  Woo  and 
Lam  [12]. 
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A 


Intruder  I 


B 


inil(B) 

send(A,B,Kb(A,Kb(M))) 


intercepts  message 
send(I,B,Kb(I,Kb(A,Kb(M)) 


recv(B,I,Ki(B,Ki(A,Kb(M))) 
send(I,B,Kb(I,Kb(M)) 


recv(B,I,Ki(B,Ki(M))> 
knows  M  ! 


recv(I,B,Kb(I,Kb(A,Kb(M)))) 

send(B,I,Ki(B,Ki(A,Kb(M)))) 


recv(I,B,Kb(I,Kb(M))) 

send(B,I,Ki(B,Ki(M))) 


Figure  1:  Counterexample  showing  secrecy  flaw  in  Dolev-Yao 


For  a  single  run  of  A  and  B,  both  properties  check  out  to  be  true.  This  happens  because  I 
is  unable  to  get  M  through  a  replay  attack,  and  so  if  A  or  B  get  the  message  they  expected, 
it  must  have  been  legally  generated. 

However,  if  either  A  or  B  is  allowed  to  have  more  than  one  session,  then  the  intruder  I  can 
replay  the  message  and  make  sure  that  A  or  B  completes  a  session  thinking  that  the  message 
which  originated  from  I  actually  came  from  an  honest  principal.  One  such  attack  is  shown  in 
Figure  2.  Here  we  have  the  same  model  as  in  the  previous  attack,  viz.,  two  sessions  of  B  and 
initiation  by  A.  In  this  case,  A  thinks  that  B  is  talking  to  her,  while  B  thinks  he  is  talking 
to  /,  so  the  authentication  property  does  not  hold. 

A  Intruder  I  B 


init(B) 


send(A,B,Kb(A,Kb(M))) 


intercepts  message 


send(I,B  ,Kb(I,Kb(  A,Kb(M)) 


recv(B,I,Ki(B,Ki(A,Kb(M))) 


recv(I,B,Kb(I,Kb(A,Kb(M)))) 

send(BJ,Ki(B,Ki(A,Kb(M)))) 


send(I,B,Kb(I,Kb(M)) 


recv(I,B,Kb(I,Kb(M))) 


recv(B,I,Ki(B,Ki(M)) 


send(B,I,Ki(B,Ki(M))) 


knows  M  ! 

send(B,A,Ka(B,Ka(M))) 


recv(B,A,Ka(B,Ka(M))) 


Figure  2:  Counterexample  showing  authentication  flaw  in  Dolev-Yao 


Since  Brutus  considers  all  principals  to  be  honest,  we  cannot  express  honesty  properties  in  the 
protocol.  This  is  a  limitation  in  the  expressiveness  of  the  specification  logic. 


2.3.2  TMN  analysis 

In  TMN,  we  have  three  honest  principals:  the  initiator  A,  the  server  5,  and  the  responder  B.  We 
model  these  as  shown  below: 


INITIATOR  - 


RESPONDER  = 


SERVER  = 


internal  {'^begin  —  initiatP^  B) 
send  (A,  5,  B,  {Ra}ks) 
receive  (s,  A,  b,  {Rb}Ra) 
internal  {‘’‘‘end  —  initiatP^b) 
receive(s,  J5,  a) 
internaK^^^er/n?  —  respond”^  a) 
send(B,  s,  a,  {Rb}ks) 
inter naU'^e?zd  -  respond” ^  a) 
receive(a,  5,  6,  {BajA'5) 
internal —  initiate”^  b) 
send(&,  5,  a) 
receive(6,  S,  a,  {Rb}Ks) 
internal  —  initiate”  ^b) 
internal(%eqin  —  respond” ^  a) 
send(5,  a,  b,  {Ra}Ru) 
internal f  “end  —  respond”^  a) 


In  the  above  model,  small  letters  (such  as  a)  are  used  in  place  of  principal  names  (such  as  A)  to 
indicate  that  the  party  represented  by  the  letter  p  may  not  be  the  principal  P,  but  some  other 
party  Q  playing  the  role  of  P. 

The  current  version  of  Brutus  requires  secret  keys  generated  by  A  and  B  to  be  represented 
as  symmetric  keys,  with  a  symmetric  key  for  7.  This  representation  allows  7’s  key  to  replace  that 
of  A  or  B  wherever  I  replaces  A  or  P.  However,  representing  secret  ke^^s  in  this  manner  ties  the 
key  to  the  principal  name  for  a  given  message.  Thus,  if  I  attempts  an  attack  in  which  it  replaces  a 
principal's  name  with  its  own  (masquerading  as  that  principal),  it  also  effectively  changes  the  key, 
often  rendering  the  attack  ineffective. 

We  checked  the  following  classes  of  properties: 

•  Secrecy:  We  want  to  check  if  the  shared  secret  Rb  remains  a  secret  from  the  Intruder  7.  More 
formally,  we  want  to  check  the  following  two  properties: 

(1)  :  -i(7  Knows  Pa) 

(2)  :  ~i(7  Knows  Pa)  A -'(7  Knows  P^) 

The  first  property  means  that  7  cannot  read  messages  passed  between  A  and  B  The  second 
property  means  that  in  addition,  7  cannot  masquerade  as  S  while  communicating  with  A. 
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Brutus  finds  both  properties  to  be  false.  First,  if  the  intruder  is  allowed  to  take  on  the  role 
of  the  server  (i.e.,  the  name  can  replace  “S'"  in  messages),  then  a  vei\y  simple  attack  is 
possible,  as  shown  in  Figure  3,  If  we  assume  that  the  intruder  cannot  masquerade  as  the 

A  I  S  I  B 


init(B) 

send(A,S,B,(Ra)Ks) 

recv(A,S,B,(Ra)Ks) 
send(I,B,A) - - 


knows ( (Ra)Ks  ) 


recv(I,B,A) 

-  seiid(B,kA,(Rb)Ki) 


recv(B,I,A,(Rb)Ki) 

knows(Rb) 

•  send(LS,A,(Ri)Ks) 


recv(I,S,A,(Ri)Ks) 

■  send(S,A,I) 

recv(S,A,I) 

send(A,S,I,(Ra)Ks) 

recv(A,S,I,(Ra)Ks) 

send(S,I,A,(Ra)Ri) 


’  recv(S,I,A,(Ra)Ri) 

knows(Ra) 


Figure  3:  Counterexample  1  showing  secrecy  flaw  in  TMN 

server,  then  we  can  still  find  an  attack.  With  a  single  session  of  S  we  are  only  able  to  find 
an  attack  that  allows  /  to  discover  Rb^  but  with  two  sessions  of  5,  /  can  also  find  /?4.  This 
latter  attack  is  shown  in  Figure  4. 

•  Authentication:  We  check  the  same  authentication  properties  as  for  the  DY  protocol.  How¬ 
ever,  in  this  case,  Brutus  deems  both  properties  to  be  true.  This  is  because  it  is  not  possible 
for  Brutus  to  represent  the  secret  key  of  I  with  the  principal  name  of  B  in  the  same  message 
as  discussed  earlier. 

•  Multiple  Intruder  Collusion:  Simmons  describes  an  attack  on  the  TMN  protocol  (described 
in  [11])  in  which  the  homomorphic  property  of  the  keys  is  used.  In  essence,  the  key  used 
in  a  single  valid  run  of  the  protocol  is  replayed  by  two  colluding  intruders  (who  could  be 
two  different  sessions  of  the  same  intruder).  Since  this  attack  depends  on  the  homomorphic 
property  of  keys,  which  cannot  be  expressed  in  Brutus,  Brutus  fails  to  catch  this  flaw. 


3  RVChecker 

RVChecker  is  a  protocol  analysis  tool  inspired  by  the  tool  Revere  developed  by  Kindred  [6]. 
Revere  features  two  new  techniques:  theory  generation,  and  the  RV  logic,  an  extended  BAN-style 
belief  logic  [Ij.  Combining  these  features  results  in  a  tool  that  is  fully  automatic;  given  a  protocol 
specification  no  further  action  is  required  by  the  user  to  analyze  the  protocol.  Whereas  Revere  is 
written  in  SML,  the  paper’s  first  author  developed  RVChecker  entirely  in  Java,  so  it  is  also  portable 
to  any  platform  for  which  there  is  a  JV'M  available. 
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I 


B 


init(B) 

send(A,S,B,(Ra)Ks) 

'  ^  recv(A,S,B,(Ra)Ks  ) 

send(S  ,B  ,1) - - 


knows ( (Ra)Ks ) 


recv(S,B  J) 

•  send(B,SJ,(Rb)Ks) 


recv(B,S,I,(Rb)Ks) 
knows ( (Rb)_Ks ) 

■  send(I,S,B,(Ri)Ks) 


recv(I,S,B,(Ri)Ks) 

■  send(S,BJ) 

recv(S,BJ) 

send(B,S,I,(Rb)Ks) 

recv(B,S,I,(Rb)Ks) 

send(S,I,B,(Rb)Ri) 


recv(I,S,A,(Ri)Ks) 

- - —  send(S,A,I) 

recv(S,A,I) 

send(A,S,I,(Ra)Ks) 

recv(A,S,I,(Ra)Ks) 

send(S,I,A,(Ra)Ri) 


recv(SJ3,(Rb)Ri) 

knows(Rb) 

-  send(I,S,A,(Ri)Ks) 


■  recv(S  J,A,(Ra)Ri) 
knows(Ra) 


Figure  4:  Counterexample  2  showing  secrecy  flaw  in  TMN 


3.1  Theory  Generation 

RVChecker  employs  Kindred  and  Wing’s  theory  generation  for  reasoning  about  small  theories  in 
limited  logics  [5].  Theory  generation  is  a  syntactic  method  of  theorem  proving  based  on  a  saturation 
approach.  The  concept  is  to  produce  a  flnite  representation  of  a  (possibly  infinite)  theory  generated 
by  a  set  of  rules  and  assumptions. 

Their  approach  divides  the  rules  of  a  logic  into  ''shrinking”  and  "growing”  rules  (as  decided  by 
any  well-defined  measure)  and  repeatedly  applies  only  the  shrinking  rules,  essentially  guaranteeing 
that  the  process  will  come  to  a  halt.  Then  to  test  whether  a  specific  formula  is  a  consequence  of 
the  rules  and  assumptions,  a  backward-chaining  search  over  the  growing  rules  is  applied,  which 
will  also  guarantee  termination.  The  sufficient  condition  for  termination  provided  by  Kindred  and 
Wing  is  the  restriction  that  a  shrinking  rule  must  still  shrink  even  when  all  of  its  premises  that  can 
be  met  by  the  conclusion  of  a  growing  rule  are  removed. 

A  consequence  of  this  condition  is  that  given  a  set  of  rules  and  a  candidate  measure,  it  is 
possible  to  automate  the  process  of  checking  a  logic  for  termination  under  theory  generation.  This 
allows  the  development  of  a  general-purpose  theory  generation  algorithm  that  can  automatically 
prove  any  judgement  of  any  logic  that  satisfies  these  termination  conditions.  Both  Revere  and 
RVChecker  implement  this  algorithm,  formally  described  in  Kindred’s  thesis  [6]. 
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In  addition  to  being  fully  automatic,  this  algorithm  has  the  potential  to  be  quite  fast;  in  his  the¬ 
sis,  Kindred  gives  figures  for  the  analysis  of  several  security  protocols  under  several  different  logics; 
the  longest  analysis  took  Revere  50  seconds  to  complete  on  a  500  MHz  processor.  RVChecker  was 
not  designed  with  processing  speed  as  a  primary  consideration;  the  protocols  analyzed  here  took 
on  the  order  of  5  minutes  to  check  on  a  500  MHz  Pentium  HI. 

3.2  RV  logic 

RV  is  a  belief  logic  developed  by  Kindred  [6]  with  a  core  similar  to  the  Burrows-Abadi-Needham 
(BAN)  logic  of  authentication  [1].  The  innovations  of  RV  lie  in  its  rules  for  responsihiUty  and  a 
technique  of  explicit  interpretations.  The  belief  rules  of  RV  are  essentially  the  same  as  those  of  BAN 
and  will  not  be  discussed  here;  the  responsibility  properties  attempt  to  account  for  the  possibility 
of  irresponsible  behavior  on  the  part  of  the  principals  of  the  protocol,  while  explicit  interpretations 
represent  an  attempt  to  address  the  dangerous  idealization  step  necessary  to  analyze  a  protocol 
using  the  BAN  logic.  In  this  section  we  will  describe  RV  rules  in  terms  of  the  symbols  listed  in 
Table  1,  for  consistency  with  the  notation  of  Kindred  [6].  (So,  for  example,  the  first  rule  in  Figure  5 
reads  ‘fif  P  sees  M,  then  P  sees  A/'".) 


Notation 

Meaning 

P  <  M 

P  sees  A/ 

P  M 

P  says  M 

P  ~  M 

P  said  M 

P  1=  M 

P  believes  M 

Q^R 

K  is  a  shared  key  between  Q  and  R 

h-Q 

K  is  Q's  public  key 

{A'}a- 

Message  encrypted  under  key  K 

Q^R 

y  is  a  shared  secret  between  Q  and  R 

P  controls  ,Y 

P  has  jurisdiction  over  A’ 

tt(A') 

A^  is  “fresh”,  that  is,  “random”  or  “new” 

Table  1:  RV  symbols 


3.2.1  Explicit  Interpretation 

BAN-style  protocol  analysis  necessarily  involves  generating  idealized  versions  of  the  messages  in  a 
protocol  and  doing  analysis  on  these  idealized  protocols  rather  than  the  concrete  protocols  intended. 
The  risk  is  that  the  idealization  might  contain  hidden  assumptions  about  the  relative  safety  of  a 
message;  BAN  fails  to  consider  other  possible  interpretations  of  the  same  concrete  message. 

RV  addresses  this  by  introducing  a  syntax  for  concrete  protocol  messages;  the  protocol  is  ana¬ 
lyzed  using  the  actual  concrete  messages  intended  for  implementation,  along  with  ‘interpretation” 
rules  that  allow  for  the  explicit  idealization  of  the  protocol.  Kindred  severely  restricts  these  inter¬ 
pretation  rules  to  prevent  invalidating  the  rules  of  the  logic  [6]. 

An  interpretation  rule  must  match  one  of  the  patterns  shown  in  Figure  5.  In  addition,  the 
concrete  message  M  cannot  contain  any  variables  specific  to  one  instance  of  the  protocol,  and  may 
not  contain  any  functions  other  than  concatenation;  the  idealized  meaning  Af'  may  not  contain 
protocol  instance  variables  or  the  encrypt  function:  and  no  concrete  message  may  match  more 
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Figure  5:  RV  Interpretation  rule  patterns.  Here  M  matches  all  or  part  of  a  concrete  message,  while 
M’  represents  its  intended  meaning 

than  one  interpretation  rule  for  a  given  protocol.  This  approach  allows  the  explicit  statement  of 
how  the  protocol  is  being  idealized,  and  placing  these  restrictions  on  the  interpretation  rules  means 
that  they  can  be  automatically  checked,  pointing  out  dubious  idealizations  to  the  user. 

Since  nonces  are  not  always  used  merely  for  freshness  or  randomness,  but  are  also  used  to  stand 
in  for  longer  pieces  of  information,  RV  also  allows  nonce-binding  operations  to  be  included  in  the 
premises  of  the  interpretation  rules;  we  do  not  use  this  feature  of  the  logic  for  either  of  the  protocols 
evaluated  here. 

3.2.2  Responsibility 

The  RV  logic  also  introduces  the  notion  of  responsibility  in  protocol  analysis.  Here  the  concept 
is  that  RV  analysis  allows  one  to  determine  whether  or  not  the  principals  involved  in  a  protocol 
are  acting  responsibly,  as  defined  by  two  properties:  honesty  and  secrecy.  Roughly  speaking,  the 
honesty  property  requires  that  a  principal  believe  any  possible  interpretation  of  a  message  he  sends, 
while  the  secrecy  property  requires  a  principal  to  believe  that  it  is  safe  for  any  intruder  to  see  all 
of  the  data  sent  in  a  concrete  message.  RV  derives  these  properties  through  the  legit  and  maysee 
operators  and  rules  described  here. 


Original  interpretation  rule 

Corresponding  legit  rule 

F  1=  Q  |c5  M 

g  1=  M'  g  1=  signed(M,  M^,  F,  g) 

p  1=  g  |!^  M' 

g  1=  legit  (Ms) 

P  \=Q  hM 

g  1=  M'  Q  1=  signed  (M,  Ms,  F,g) 

F  1=  g  h  M' 

g  1=  legit  (Ms) 

P  <3  M 

g  N  M' 

P<M' 

Q  1=  legit  (M) 

Table  2:  Honesty  rules  corresponding  to  protocol  message  interpretation  rules 

The  legit  operator  works  in  conjunction  with  the  interpretation  rules  introduced  in  the  previous 
section;  when  analyzing  a  protocol,  for  each  interpretation  rule,  a  corresponding  rule  is  introduced, 
according  to  the  proper  rule  from  Table  2.  The  RV  logic  also  has  rules  that  allow  one  to  derive  that 
the  encr3^ption  of  a  legitimate  or  honest  message  is  also  honest,  and  the  concatenation  of  two  honest 
messages  is  honest.  It  introduces  a  concept  of  signed  messages,  with  the  idea  that  any  message 
encrypted  under  a  private  or  shared  key  or  combined  with  a  shared  secret  is  signed.  Then  to  check 
the  honesty  of  a  principal  P  in  connection  with  a  given  concrete  message  it  sutfices  to  derive 


P<Q  ^  R  P<Q  R  P<^^Q  Ki  =  Kj  ^ 

P  \=  Q  maysee  K  P  |=  Q  maysee  V"  P  |=  Q  maysee  K2 

P<Q  maysee  Y  P<iQ  <  Y  P  |=  Q  maysee  .Y 

P  \=  Q  maysee  Y  P  |=  Q  maysee  Y  P  \=  Q  maysee  {A  ]k 

P  \=  Q  maysee  ( A ,  1")  Po  A  Q  P  \=  Z  maysee  A^ 

P  \=  Q  maysee  A^  P  \=  Z  maysee  K  P  \=  Q  maysee  A' 

P  \=  Q  maysee  A^  P  |=A  Q  P  \=  Q  maysee  A'  P  \=  Q  maysee 
P  \=  Z  maysee  {A  } a*  P  \=  Q  maysee  [X.Y] 

P  \=Q  maysee  A^  P  \=  R  maysee  A'  P  |=  Q  R 
P  1=  Z  maysee  {A  }a' 


Figure  6:  RY’s  maysee  rules 

P  1^  legit  (yl/)  [6]. 

The  maysee  operator  communicates  that  it  is  acceptable  for  a.  given  principal  to  see  a  piece  of 
information.  RV’s  maysee  rules  specify  that  if  information  is  public,  then  any  principal  believes 
that  any  other  principal  may  see  it;  a  principal  is  allowed  to  see  anything  he  or  she  has  alread}^ 
seen  before;  a  principal  may  see  anything  that  an  intruder  may  see,  and  so  on.  For  a  complete  list 
of  RV’s  maysee  rules,  see  Figure  6.  To  check  secrecy  properties  in  RV,  the  protocol  analyst  adds 
a  principal  I  (the  Intruder)  and  checks  that  for  each  message  M  and  sender  5,  S  |=  I  maysee  M 
[6]. 

3.3  RVChecker  Protocol  Analysis 

Protocol  analysis  with  RV  and  theory  generation  involves  several  phases: 

1.  A  specification  is  supplied,  consisting  of  a  set  of  messages  between  principals,  a  set  of  inter¬ 
pretation  rules  conforming  to  the  restrictions  listed  above,  a  list  of  the  principals  involved,  a 
set  of  belief  goals  for  the  protocol,  and  a  set  of  initial  assumptions  about  the  beliefs  of  the 
principals  involved. 

2.  Theory  generation  is  applied  to  the  initial  assumptions  to  generate  Tq^  the  consequence  closure 
of  the  assumptions  under  RV. 

3.  For  each  message  Mj  with  sender  5/  and  recipient  formula  Ri<Mi  is  added  and  theory 

generation  is  re-applied  to  compute  the  theory 

4.  Secrecy  is  checked:  Si  |=  /  maysee  Mi  G  Ti-i. 


5.  Honesty  is  checked:  Si  |=  legit  (Mi)  G 

6.  For  each  belief  goal  g,  check  that  g  eTn,  where  n  is  the  number  of  messages. 

In  this  section,  we  give  the  results  of  protocol  analysis  for  the  selected  suite. 

RVChecker  identified  flaws  in  both  the  DY  and  TMN  protocols;  here  we  present  the  analysis 
of  each.  The  suite  nicely  points  out  some  weaknesses  of  the  RV  approach,  as  well  as  its  strengths; 
for  example,  we  were  able  to  And  flaws  through  an  inability  to  meet  belief  goals,  but  discovering 
these  flaws  required  extensive  familiarity  with  the  RV  logic  to  isolate  the  necessary  (or  flawed) 
additional  assumptions.  In  addition,  knowing  that  some  dubious  assumptions  are  necessary  does 
not  necessarily  indicate  how  an  attacker  can  take  advantage  of  these  assumptions  -  while  in  these 
cases  we  knew  of  the  attacks  a  priori,  in  actual  analysis  using  RVChecker  on  other  protocols  this 
will  not  in  general  be  the  case. 

3.3.1  Dolev-Yao  analysis 

RVChecker  can  quickly  identify  one  fault  in  the  DY  protocol:  it  provides  no  authentication.  One 
might  assume  that  desirable  belief  goals  for  DY  would  be  “R  believes  it  is  A  who  says  M,”  and  “A 
believes  B  says  that  it  is  A  who  says  M”  (formally,  A  \=  B  (A  M)),  however,  since  there 
is  no  signature  and  no  previous  shared  secret  of  any  sort,  this  belief-oriented  set  of  goals  cannot 
be  achieved.  In  any  case,  the  main  goal  of  the  protocol  as  introduced  by  Dolev  and  Yao  is  secrecy, 
so  the  belief  goals  can  be  weakened  to  the  “seeing”  goals  “i?  sees  that  A  said  M”  and  “.4  sees 
that  B  sees  A  said  M”,  while  we  analyze  the  honesty  and  secrecy  properties  of  the  protocol.  Even 
these  further  weakened  goals  cannot  be  reached  without  breaking  an  interpretation  rule  restriction: 
because  RV  and  RVChecker  do  not  allow  compositional  rules,  there  is  no  way  for  a  principal  to 
derive  that  when  she  sees  [A.{Y}a]  and  has  the  kej'  R,  then  she  sees  A  and  1  together  in  the 
same  message.  Thus  our  interpretation  rules  include  encryption  and  specify  protocol  principals  (so 
that  we  may  connect  the  encryption  key  with  the  principal  who  may  decrypt  it): 

B<[{X}Kb.Q]  A<[{X}Ka.Q] 

B<Q\r^X  4[<((5<(A  h  A')) 

With  these  interpretation  rules  and  the  proper  public  key  belief  set: 

A  A  A  1=1-^  B 

B  1=1-^  A  B  |~1~>  B 

RVChecker  finds  that  the  “seeing”  goals  are  satisfied. 

The  honesty  goals  require  additional  assumptions  to  be  met.  The  first  required  assumption  is 
that  A  \=  A  |~  M,  which  is  necessary  to  assume  because  only  the  recipient  sees  the  message  in 
RVChecker’s  analysis.  We  also  require  the  assumptions: 

A  1=  legit  (A)  A  1=  legit  (B) 

B  1=  legit  (A)  B  \=  legit  (JB) 

in  order  to  get  around  the  fact  that  namestamps  rather  than  kej^s  are  used  to  provide  authentication. 
With  these  assumptions,  it  is  eas,y  to  derive  the  appropriate  legit  belief  for  the  first  message. 
After  the  first  message,  B  <\  A  |~  M  can  be  used  to  derive 

5  1=  H  <  A  |~  M 
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which  allows  us  to  derive  the  legit  properties  for  the  second  message. 

The  secrecy  goals  are  also  met,  requiring  only  two  assumptions:  A  \=  B  maysee  Af,  which 
seems  obvious  since  A  is  sending  M  to  B\  and  B  |=  .4  maysee  A/,  which  seems  reasonable  once  B 
sees  that  A  |~  A/.  With  these  assumptions,  RVChecker  easily  derives  that  the  secrecy  properties 
hold. 

The  DY  protocol,  however,  was  designed  to  have  a  secrecy  flaw;  thus  our  results  represent  either 
a  shortcoming  of  RV's  secrecy  rules  (meaning  they  are  unable  to  account  totally  for  multiple-run 
attacks)  or  an  invalid  assumption.  The  assumption  that  B  \=  A  maysee  M  allows  the  secrecy 
check  to  succeed  for  the  second  message;  without  it,  B  cannot  derive  that  /  maysee  {A/}/Ca  .  Thus 
it  might  be  tempting  to  conclude  that  this  assumption  is  invalid;  however,  Dolev  and  Yao  also 
give  an  example  of  a  protocol  with  perfect  secrecy,  for  which  this  assumption  is  required  for  RV  to 
derive  the  secrecy  properties.  This  shortcoming  is  a  result  of  a  conscious  design  decision  by  RY's 
creator  which  results  in  a  conservative  approach  to  secrecy;  thus  sometimes  these  rules  will  lead 
to  the  conclusion  that  a  secrecy  flaw  is  present  when  in  fact  none  is.  Here  the  secrecy  flaw  comes 
both  from  lack  of  authentication  and  double  encryption,  but  RV\s  rules  do  not  allow  us  to  isolate 
the  double  encryption  as  a  source  of  the  flaw. 

3.3.2  TMN  analysis 

Through  analysis  with  RVChecker  we  were  able  to  find  belief  and  responsibility  errors  in  TMN. 
Since  TMN  is  a  key-exchange  protocol,  we  start  with  the  belief  goals.  Generally,  we  would  like  to 
have  both  A  and  B  believe  that  Rb  is  a  shared  key  between  them,  and  further  we  would  like  both 
principals  to  believe  that  the  other  principal  shares  their  belief,  resulting  in  the  goals: 

.4  1=  .4  A  B  B  1=  .4  A  B 

.4  1=  B  1=  .4  A  B  B  1=  A  1=  .4  A  B 

Since  there  is  no  direct  authentication  in  this  protocol,  however,  the  bottom  two  goals  are  impos¬ 
sible,  so  we  will  settle  for  the  goals: 

.4  1=  .4  A  B  B  1=  .4  A  B  S  \=aAb 

We  also  have  a  problem  in  that,  as  specified  in  Section  1.2.1,  any  interpretation  rule  which  matches 
message  1  or  3  will  match  both,  yet  they  have  different  interpretations;  to  solve  this  problem  we 
add  tags  REQ  and  RSP  to  these  messages  (which  simulate  the  state  that  S  would  have  to  maintain  in 
the  concrete  protocol).  If  we  try  to  write  the  interpretation  rules  now,  we  find  one  more  problem: 
as  with  DY,  RV  is  unable  to  derive  that  if  a  principal  sees  [Ah{V}A'],  then  that  principal  sees 
(-V,  V).  Thus  in  our  idealization  step  we  have  already  identified  one  potential  attack:  an  attacker 
can  change  the  names  in  the  messages  being  passed  around  without  changing  the  keys;  thus  he 

could  change  a  message  from  A  to  S  to  say  [S.A.I. . . .]  rather  than  [S.A.B - ].  To  fix  this  problem, 

we  encrypt  the  entire  contents  of  messages  1  and  3  rather  than  just  the  keys: 

A  — S  :  {[REQ.S.A.B.RaJjK, 

B — >S  :  {[RS?.S.B.A.Rb]}Ks 

Then  our  interpretation  rules  for  these  messages  are  relatively  straightforward: 

P  <  [REQ,P,Q.R.K]  P  <  [RSP. P,Q.R.K] 

P<iP^Q  P<Q  \^Q  ^  R 
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However,  since  the  specification  of  TMN  calls  for  bitwise  exclusive-or  encryption  in  the  final  mes¬ 
sage.  we  cannot  modify  it  to  encrypt  the  entire  contents.  Instead,  we  will  break  the  restriction  that 
an  interpretation  rule  cannot  include  any  protocol  instance  variables,  which  is  reasonable  because 
in  any  single  run,  A  only  expects  to  get  a  key  for  one  person: 

P  1=  S  |«  K 

P  \=  S  \^P^  B 

Note  that  in  this  rule,  S  refers  to  a  protocol  constant,  the  server  5. 

To  check  our  belief  goals,  we  require  several  assumptions.  Besides  the  jurisdiction  assumptions 
(involving  which  principals  are  allowed  to  control  the  keys  used  by  other  principlas)  necessary,  the 
interesting  assumptions  are 

A  1=  A  S 


and 


B 


I  4 

=  A  i — ^ 


B 


since  A  and  B  are  responsible  for  generating  these  keys.  The  second  of  these  assumptions  satisfies 
our  second  belief  goal.  To  satisfy  our  first  belief  goal,  however,  we  require  an  additional  assumption, 
which  points  out  a  second  attack.  For  A  \=  A  B,  we  must  infer  the  following  sub-goals: 


A  1=  S  controls  A  t  B 
A  1=  S  j^A^^B 

The  first  sub-goal  is  the  obvious  jurisdiction  assumption.  The  second  sub-goal  can  be  derived 
through  our  interpretation  rule,  if  we  can  infer  A  |=  ,S  Rb.  This  inference  requires  the  assumption 
A  \=  that  is,  A  must  assume  that  Rb  is  freshly  generated.  In  fact,  this  points  to  the  attack 

found  by  Simmons  [11]  in  which  twm  collaborating  intruders  use  keys  which  are  not  fresh  to  find 
.4  s  key. 

The  final  belief  goal  is  also  a  source  of  difficulty:  to  derive  S  \~  A  < — b  J3,  we  need  to  infer  that, 
for  some  P: 

5  1=  F  controls  A  B 
S\=P\^  A  A  B 

Given  the  definition  of  the  protocol,  it  is  a  reasonable  assumption  that  P  =  B,  since  B  generates  Rb. 

Rb 

We  end  up  with  an  authentication  problem,  however:  while  we  can  derive  that  S  <3B  ]«  ^4  ^ H, 
the  protocol  does  not  have  sufficient  public  key  architecture  for  authentication.  Thus  there  is 
no  way  for  S  to  become  convinced  that  H  | «  .4  ^  B.  This  seems  to  correspond  again  to  a 

masquerading  attack,  in  which  the  intruder  I  poses  as  B  and  convinces  A  that  he  shares  a  key  with 
B  rather  than  I. 

When  checking  responsibility,  we  find  that  under  reasonable  assumptions  the  first  three  messages 
(as  modified)  will  satisfy  honesty,  while  because  of  the  belief  problem  above,  the  fourth  message 

cannot  satisfy  the  honesty  property,  since  A  will  interpret  5’s  message  as  meaning  5  |«  A  ^ — >  B, 
and  S  does  not  believe  this.  Thus  RV  affords  two  opportunities  to  find  this  error  (although  we 
admittedly  added  the  third  belief  goal  only  because  we  suspected  that  its  failure  lead  to  the  failure  of 
the  honesty  check  for  the  final  message).  Similarly,  the  secrecy  property  fails  for  the  final  message, 
because  since  5  is  not  convinced  that  Rb  is  really  a  shared  key  for  A  and  B,  the  maysee  rules  do 
not  allow  us  to  infer  that  5  |=  A  maysee  Rb. 
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4  Comparison 

In  this  paper  we  ha.ve  highlighted  the  approaches  of  two  fully-automated  protocol  analysis  tools, 
Brutus  and  RVChecker,  by  presenting  their  analyses  of  two  cryptographic  protocols.  Since  both 
tools  found  flaws  in  both  protocols,  we  attempt  to  sort  through  the  advantages  and  disadvantages 
of  each.  In  the  next  section,  we  suggest  a  heuristic  for  their  combination,  exploiting  the  advantages 
of  both. 

Brutus  and  RV'Checker  both  represent  fully-automated  protocol  analysis  techniques;  that  is, 
given  a  specification,  neither  tool  requires  further  intervention  from  the  user  to  complete  its  analysis, 
in  contrast  to  the  tools  examined  in  [4].  The  speed  of  both  approaches  also  allows  a  more  interactive 
approach  in  that  the  protocol  and  assumptions  can  be  changed  and  the  results  analyzed  (relatively) 
quickly  -  but  both  tools  require  significant  knowledge  of  the  underlying  model  used  in  analysis; 
Brutus  for  the  specification  of  security  properties  and  RVChecker  for  the  interpretation  of  analysis 
results. 


System 

Dolev- 

Auth 

Yao  Flaws 
Secrecy 

TMN 

Aiith/Secrecy 

Flaws 

Simmons/Key 

RYCliecker 

YES 

NO 

YES 

YES 

Brutus 

YES 

YES 

YES 

NO 

Table  3:  Results  of  protocol  analysis.  YES  indicates  that  the  system  identified  the  flaw. 

Table  3  summarizes  the  results  of  our  comparison.  It  is  interesting  to  note  that  while  both 
Brutus  and  RVChecker  found  flaws  in  the  TMN  and  DY  protocols,  the  type  of  flaws  found  by 
each  were  somewhat  different.  For  example,  while  both  tools  identified  the  authentication  failure  in 
TMN,  RV  was  able  to  suggest,  without  any  specific  knowledge  of  the  encryption  schemes  used,  that 
it  may  be  possible  to  attack  the  protocol  with  non-fresh  session  keys.  And  for  DY,  RV  identified 
an  authentication  flaw  but  even  with  a  reasonable  assumption  (which  holds  for  a  slightly  modified 
but  secure  version  of  the  protocol)  was  unable  to  identify  the  security  flaw  that  Brutus  easily 
identified.  Therefore,  while  it  might  be  tempting  to  claim  that  each  tool  always  identifies  certain 
types  of  flaws,  we  can  see  from  this  small  set  of  protocols  that  neither  tool  consistently  identifies 
the  same  types  of  flaws. 

5  Combination 

In  addition  to  having  the  advantage  of  catching  more  flaws  when  used  in  combination,  the  theory 
generation  and  model-checking  approaches  seem  to  present  a  certain  complementarity.  Analysis 
using  theory  generation  and  belief  logics,  as  implemented  in  Revere  and  RVChecker,  allows  the 
identification  of  critical  assumptions  which  allow  or  prevent  a  protocol  from  meeting  its  belief  goals 
or  from  passing  honesty  or  secrecy  checks.  Without  prior  knowledge  of  protocol  flaws,  however, 
it  may  be  difficult  to  see  how  the  failure  of  an  assumption  can  be  marshalled  into  an  attack; 
further,  as  in  the  case  of  the  DY  assumptions,  it  may  be  diflhcult  to  identify  which  assumptions  are 
questionable.  Using  model-checking,  as  in  Brutus,  yields  actual  attacks,  but  especially  for  lengthy 
counterexamples,  it  can  be  difficult  to  discern  why  the  attack  works,  or  what  assumptions  about 
the  protocol  are  being  violated. 
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5.1  A  Motivating  Example 

As  an  example,  in  the  RVChecker  analysis  of  DY,  we  were  able  to  find  that  the  secrecy  property 
fails  if  B  does  not  believe  that  A  maysee  M ;  however  knowing  that  this  is  a  crucial  assumption 
does  not  give  us  any  knowledge  of  liow  an  attacker  might  take  advantage  of  it.  On  the  other  hand, 
with  our  knowledge  of  how  the  attack  works,  Brutus  was  quickly  able  to  find  an  attack  which 
yielded  the  message;  however  this  does  not  give  us  a  high  level  explanation  of  why  the  protocol 
might  have  failed.  Using  RVChecker  and  Brutus  in  combination,  we  see  that  the  protocol  fails 
because  B  \=  A  maysee  M  and  we  are  given  an  example  of  how  this  flaw  can  be  utilized  to  yield 
an  error. 

Further,  the  fact  that  RVChecker  needed  both  assumptions  B  |  =  .4  maysee  M  and  A  |  = 
B  maysee  M  brings  out  the  symmetry  in  the  roles  that  might  be  played  by  A  and  B  in  an  attack. 
This  means  that  in  Brutus,  if  we  want  the  intruder  to  take  on  the  role  of  B,  we  can  introduce 
additional  runs  of  A  and  vice-versa.  As  discussed  in  Section  2.3,  different  combinations  of  runs  of  A 
and  B  lead  to  different  attacks  (from  that  mentioned  in  [-3]),  one  of  which  is  presented  in  Figure  1. 

5.2  A  General  Methodology  for  Combined  Analysis 

In  general,  we  can  think  of  the  following  two  ways  to  combine  these  approaches: 

1.  From  Assumptions  to  Counterexamples:  We  can  use  RVChecker  to  identify  crucial  assump¬ 
tions,  and  then  use  our  knowledge  of  these  assumptions  to  search  for  counterexamples  in 
Brutus. 

2.  From  Counterexamples  to  Assumptions:  We  can  search  for  counterexamples  in  Brutus  and 
use  this  knowledge  to  isolate  important  assumptions  in  RVChecker. 

In  this  section,  we  present  short  heuristics  that  are  suggested  by  the  previous  example.  In  the  next 
section,  we  show  more  examples  that  support  these  heuristics. 

5.2.1  Assumptions  to  Counterexamples 

To  see  how  to  move  from  RVChecker  analysis  to  counterexamples  in  Brutus,  observe  that  if  an 
assumption  held  by  principal  A  is  both  dubious  and  crucial  for  satisfaction  of  some  property,  then 
it  most  likely  falls  under  one  of  two  cases: 

1.  A  believes  something  about  her  own  behavior;  in  this  case,  we  can  use  Brutus  to  search  for 
counterexamples  in  which  the  intruder  plays  the  role  of  A  by  modeling  extra  sessions  of  the 
other  principals. 

2.  A  believes  something  about  the  behavior  of  another  principal  B,  in  which  case  we  allow  the 
intruder  to  play  the  role  of  B  in  our  analysis  with  Brutus  by  modeling  extra  sessions  of  A. 

In  the  protocols  presented  here,  the  counterexamples  that  were  found  by  Brutus  can  be  motivated 
in  this  fashion  by  failures  found  using  RVChecker.  For  example,  the  extra  assumptions  needed  for 
secrecy  in  Dolev-Yao  point  to  ways  in  which  extra  sessions  of  A  or  B  can  be  utilized  to  generate 
an  attack;  we  apply  this  heuristic  to  the  TMN  protocol  in  Section  5.3. 
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5.2,2  Counterexamples  to  Assumptions 

In  the  second  case,  we  would  like  to  use  RVChecker  to  determine  which  of  a  protocol  designer’s 
assumptions  about  a  protocol  fail  in  a  counterexample  generated  by  Brutus.  To  combine  the  tools 
in  this  direction,  we  model  the  entire  counterexample  trace  as  a  protocol  in  RVChecker;  note  that 
this  model  will  have  the  intruder  I  involved  as  a  participating  principal.  We  then  proceed  to  add 
assumptions  about  each  of  the  principals  until  the  goal  properties  (secrecy,  honesty,  authenticatjon, 
etc.)  become  satisfied.  Some  of  these  assumptions  will  be  about  7.  The  assumptions  held  about 
I  when  he  plays  the  role  of  principal  Q  will  then  indicate  assumptions  that  the  protocol  designer 
either  explicitly  or  implicitly  made  about  Q  and  that  I  has  used  to  subvert  the  protocol.  Thus 
we  can  identify  the  faulty  assumptions,  which  will  hopefully  lead  to  a  better  understanding  and 
possibly  a  simple  fix  to  the  protocol. 

5.3  More  examples:  DY  attack  and  TMN 

In  this  section,  we  show  how  the  methodology  outlined  in  the  previous  section  can  be  applied  to 
the  two  protocols  we  have  studied. 

5.3.1  DY  Assumptions  from  Attack 

Section  5.1  indicates  how  RVChecker  can  be  used  to  guide  Brutus  by  indicating  which  sessions 
to  model.  Going  the  other  way,  we  can  also  model  the  attack  produced  by  Brutus  as  a  protocol 
in  RVChecker  and  analyze  this  protocol  to  determine  what  assumptions  about  the  intruder  are 
necessary  to  satisfy  the  secrecy  properties.  Thus  we  model  the  second  attack  listed  in  Section  2  as 
a  protocol  with  six  messages,  the  first  two  between  A  and  B  and  the  last  four  between  A  and  7, 
and  attempt  to  satisfy  the  secrecy  properties.  In  addition  to  the  properties  listed  in  Section  3.3.1 
and  the  necessary  assumptions  about  7’s  ID  and  public  key,  we  find  that  these  assumptions  are 
necessary  to  satisfy  secrecy: 

7  1=  7  maysee  M  I  \=  B  maysee  M  B  \=  I  maysee  M 

This  pinpoints  the  assumption  that  both  principals,  particularly  B  must  believe  that  it  is  safe  for 
the  recipient  to  see  the  message  A7,  when  in  fact  because  of  the  lack  of  authentication  it  could 
potentially  be  an  intruder  receiving  the  message.  This  gives  us  some  high-level  insight  into  what 
went  wrong  with  the  design  of  the  protocol. 

5.3.2  TMN 

We  also  applied  both  heuristics  to  the  TMN  protocol.  In  our  analysis  with  RVChecker  (Section 
3.3.2)  we  found  that  it  was  necessary  either  to  change  the  protocol  or  allow  the  server  S  to  use 

inappropriate  interpretation  rules  to  satisfy  the  goal  S  \=  A  B;  and  that  to  satisfy  secrecy,  we 
required  the  additional  assumption  that  S  |=  A  maysee  Rb.  So  following  rule  2  of  our  heuristic, 
we  can  model  an  extra  session  of  5  in  Brutus  and  allow  7  to  play  both  A  and  B;  the  result  is  the 
attack  shown  in  Figure  4,  in  which  7  manages  to  retrieve  Ra  from  the  server.  Thus  we  arrive  at  the 
conclusion  that  the  lack  of  authentication  in  this  protocol  results  in  inappropriate  interpretation  of 
messages  and  inappropriate  assumptions  that  can  be  marshalled  into  an  attack  by  7. 

Going  in  reverse,  we  can  also  identify  these  interpretation  rule  errors  and  faulty  assumptions 
by  modeling  the  trace  from  Figure  4  as  a  protocol  and  attempting  to  satisfy  the  secrecy  goals.  Of 
particular  interest  is  the  secrecy  of  the  message  which  7  receives  from  S  revealing  Rb.  To  achieve  the 
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goal  5  1=  P  maysee  {Rbjni,  we  must  satisfy  the  sub-goals  S  \=  I  maysee  Rb  and  S  \=  S  < — I. 
The  first  can  only  be  satisfied  by  assumption,  which  reveals  our  first  broken  assumption  -  in  the 
original  protocol  this  translates  to  S  |=  A  maysee  Rb,  when  S  has  no  proof  that  the  key  is  actually 
intended  for  A.  The  second  sub-goal  can  only  be  satisfied  by  forming  interpretation  rules  that  do 
not  follow  the  patterns  specified  in  [6],  since  S  must  believe  an  unauthenticated  message  from  I. 
It  follows  that  in  the  original  protocol  S  must  believe  unauthenticated  messages  from  A  and  B, 
which  highlights  the  second  error  in  the  protocol,  that  is,  the  lack  of  proper  authentication. 

Thus,  in  both  cases  we  are  able  to  apply  our  heuristics  to  the  TMN  protocol,  producing  a  more 
complete  analysis  through  the  combination  of  the  tools  than  we  were  able  to  produce  with  either 
alone;  in  addition,  the  combination  of  the  tools  is  able  to  catch  more  errors. 

6  Concluding  Remarks 

In  this  paper,  we  ha.ve  compared  the  approaches  and  capabilities  of  two  cryptographic  protocol 
analysis  tools  -  Brutus  and  RVChecker  -  by  analyzing  two  security  protocols  with  known  flaws. 
Neither  tool  isolated  all  of  the  flaws  in  these  protocols,  but  each  tool  missed  diflferent  flaws;  the 
complementary  nature  of  their  approaches  suggested  that  it  might  be  possible  to  combine  these 
tools  resulting  in  a  more  powerful  yet  still  fully  automated  approach  to  formal  protocol  analysis. 
We  do  not  claim  that  the  methods  suggested  here  for  combining  these  two  approaches  are  rigorous 
or  complete,  however,  these  methods  of  combination  represent  a.  beginning.  Future  work  could  see 
how  they  can  be  formalized  and  extended  beyond  the  two  protocols  presented. 
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